BBS Toolkit/BBS Toolkit.iso/doors_2/xrdor211.zip/NEWIN206.DOC

Text File | 1993-01-31 | 23KB | 404 lines

(these are in reverse order - XRSDoor 2.06 back to XRSDoor 2.01)



    XRS "eXpress Response System" (R) Door version 2.06 changes:


0) Lord help us - this one's been moved from BC++ 2.0 to Borland C++ 3.0!
 Watch for "unusual" new features, please!  I had to turn optimization off
 for one entire module (the name lookup binary search) already.

1) XRSDoor supports "No Reply" areas if the SysOp enables it (only!).  Any
 area you have marked "Read-Only" becomes a read-write but not quote-reply
 message area.  (in other words, the use can make an area readable, and they
 can enter an original new message but they cannot quote or reply to existing
 messages.  This support is exclusive - one way or the other - either "Read
 Only" really means read-only, or it means no-reply.  Put the new "No Reply"
 parameter into your QMXSETUP.CFG control file to enable this feature.  Note
 that it's an all or nothing proposition: either you have all areas marked
 this way really read-only, or they're all no-reply!  If a user enters any
 new message into the "No Reply" conference, it is always marked "public".
 YOU ARE OVERRIDING THE BBS SECURITY AND ANYONE CAN ACCESS AND LEAVE MESSAGES
 IN ALL CONFERENCES MARKED "READ-ONLY" AS LONG AS THEY HAVE AT LEAST A "READ
 ACCESS" LEVEL FOR EACH GROUP IF YOU ENABLE THIS OPTION!  Note also that the
 areas which are "Read-Only" (regardless of whether or not you turn this on)
 will still be read-only for all XRS users except XRS 5 "Mod 3" or higher.
 (in other words, only XRS 5 "Mod 3" or later supports "No Reply")

2) Chuck Forsberg seems to keep changing DSZ.COM to suit, and this time he's
 restricted the 'restrict' command to registered copies.  XRSDoor has always
 used the "restrict" on uploads to protect you from users to uploading to
 current directory only.  This is now a registered DSZ 'feature', so XRSDoor
 doesn't use it by default.  (see below - you can re-enable it with DSZPARM
 or the "SET DSZOPT=-r" environment string if you have a registered copy)

3) We still didn't get "DSZPARMS xxx" right in 2.05: you couldn't change any
 parameter appearing after the protocol.  In this version, you can use "%s"
 (lower-case 's'!) to substitute for the protocol, if you don't the protocol
 is added to the end of your parameter string.  Example: "DSZPARMS handshake
 both restrict estimate 0 $B %s -m" to turn on "MobyTurbo".

4) The "Limit xxxx" parameter allows you to set it up to 20,000 messages!
 You should use this feature with caution!  Even though XRSDoor computes the
 time left -vs- time required to pack 'x' number of messages, it is possible
 that a user with download problems could conceivably tie up your system for
 an extended period of time, although XRSDoor checks time remaining between
 offers to try again on downloads, so if they aren't dialed in at 9600+ and
 receiving at 300 baud, it shouldn't be a problem.  A 20,000-message mailbag
 is about 20MB in size compressed, and requires 60 to 65MB free space on the
 drive to create and pack! (and quite a while to transfer even at 1700 cps!)
 Users should be cautioned that picking more than 5000 messages in a mailbag
 may be unreadable in a system without EMS memory (the heap expander could
 allow me to go up to 256K messages, but that's a bit much!).  A full 20,000
 message mailbag requires a system with at least 2MB EMS memory!.

5) XRSDoor will allow you to call it with command-line parameters which can
 either eXpress-Upload mail (only) or eXpress-Download mail (only).  To use
 these functions, put "/UPLOAD" or "/DownLoad" as the only parameter on the
 command-line in your BBS menu configuration.  Auto-Download sends up to the
 the limit you defined in your "Limit xxx" parameter (default 1500).  Local
 (console) users cannot upload so this option make no sense for them!  (but
 XRSDoor checks for it though - and gracefully exits if you try)  Downloads
 are allowed for Local users, but they are saved in compressed format and
 not transmitted, of course.

6) You can force XRSDoor to use RA files with "BBSType RA" in QMXSETUP.CFG
 or force XRSDoor to put any of the following identifiers into the USERx.XRS
 file: "PCBoard", "Quick", "Super", "WildCat", "Tag" and "MKBBS".  Only XRS
 5.0 "Mod 3" and later recognize the last two.  Don't read any more into this
 than it says: you can force XRSDoor to place one of the above identifiers in
 your mailbags, so that XRS returns mail with origin lines that agree with
 the actual BBS type you are using, regardless of which control files you are
 using - but you still must have either a complete set of QuickBBS (either
 2.0x-2.6x or 2.7x+) or RA format control files and message databases to run
 XRSDoor!  Note that one special case: "BBSType RA" causes XRSDoor to ignore
 any QuickBBS control files which might be in the directories (because you
 use QEcho, or whatever) and only pay attention to RA configuration files.
 In all other cases, the *only* effect is to cause XRSDoor to put the tag in
 USERx.XRS which corresponds to the above BBS type.

7) You can force the "EXPRESS.BBS" file to be echoed to the console (i. e.
 displayed online) by placing an exclamation point ("!") as the first byte
 in the file (in which case it is skipped).  This might be useful in notices
 about program changes or new features, which you could run for a short time
 after a new program release, etc.  A sample "EXPRESS.BBS" file is enclosed.

8) You can force XRSDoor to export 'kludge' lines either only for the SysOp
 or for all users.  "Show SysOp Kludges" in QMXSETUP.CFG will turn it on for
 the SysOp only, or "Show User Kludges" will turn them loose for everyone.
 For the SysOp (only) in either case, XRSDoor exports any SEENBY and/or PATH
 lines it finds - but never shows these for users.

9) XRSDoor marks messages "To You" for aliases, and searches outside selected
 areas for messages to the alias if that "<O>ption toggle" switch is set.

10) The cursor is lined-up correctly under the first character of menus.




      XRS "eXpress Response System" (R) Door version 2.05 changes:

1) The "Short Month" displayed for saved mailbags is corrected.  This was off
 by one month before (and I had two tables in XRSDoor with the same data).

2) Packing with "ARC" (now using PKPak) with named mailbags works again.

3) The previously undocumented "DSZPARMS xxx yyy zzz etc up to 65 characters"
 parameter in QMXSETUP.CFG is fixed (and documented <grin>...).  You can use
 this to fine-tune your DSZ.COM or GSZ.EXE calls - the default parameters are
 "handshake xxx estimate 0 yyy" where 'xxx' = "both" if user > 2400 baud or
 "LockBaud" otherwise "on" and 'yyy' = the actual connect rate (as opposed to
 the possibly locked FOSSIL rate).

4) The bug that cause QuickBBS 2.75 "Alias Only" areas to be marked "Alias
 Allowed" instead is fixed, and another bug which caused it not to properly
 update "LASTREAD.BBS" was fixed as well.





      XRS "eXpress Response System" (R) Door version 2.04 changes:


1) XRSDoor uses "4D-PACK.XRS" (instead of 4D_ - the underscore messes up the
 XRS CP/M clone (CRR) written by Paul Martin).  If you had "4D_PACK.XRS" out
 there, you need to change the name to "4D-PACK.XRS" for version 2.04!

2) When XRSDoor is run under "PackBags" in 'demand pack' mode, it will check
 for uploaded files as if the user were online, therefore enabling processing
 of UREQ (UserRequest) messages to XRS to add or delete echomail areas.  Note
 that file-requests are not possible in this mode.  If you have MkXrs enabled
 it *is* called using the "MKXRS L FIRSTNAME LASTNAME" parameter sequence.

3) XRSDoor is compiled with Borland C++ "BCCX" and the coding error in the
 "Scroll" routine in Borland's library has been repaired.

4) If you tell XRSDoor to erase all prepacked mail and the mail is not in
 the current subdirectory, you no longer go into an endless loop. (sorry!)
 It also displays a list of the filenames as it deletes them.

5) The date each prepacked mailbag was created is displayed along with the
 filesize and name.

6) The misleading "Quit .. and delete" message if you are downloading some
 prepacked mail is fixed (if you pick "<Q>uit" at this point, the prepacked
 mail is *not* deleted!).

7) If you hit only "<ENTER>" when prompted to delete all prepacked mail,
 XRSDoor no longer leaves the sub-menu and continues - instead it allows
 you to chose between "<D>ownload", "<S>ave" and "<E>rase" again.

8) If "PackBags" is run and the is no "QMX_CONF.SYS" file found, it exits
 gracefully without hanging the system. (oops #2!)

9) If XRSDoor detects an "unknown file compression" or alien upload in the
 inbound directory, when it moves the file into the "XRS_DOOR.BAD" subdir,
 it places a messages telling the SysOp into the system log file.

10) Now says "Prepacked" mailbags where it used to say "Packpacked" (must
 have been a late-night event!).

11) If "Alias Required" is set (or force handle), then XRSDoor turns on a new
 bit in ACCESSx.XRS which tells XRS not to bother to ask.

12) XRSDoor now uses a new "Exec_Swap()" routine which was written by Thomas
 Wagner of Ferrari GmBH in Germany.  It supports swap to LIM/EMS, XMS or disk.
 Note that the "Swap" parameter in QMXSETUP now ignores any disk specified,
 and execSwap() uses the "SET TEMP=" from the environment instead.  For best
 speed, this should point to a RAMdrive (only matters if you have no [or
 insufficient] LIM/EMS or XMS memory).  This is a faster and slightly more
 efficient routine than the old swapper - it only leaves a 'stub' of about
 1.5K in memory.  Note that there is a potential problem in disk swapping
 usage - since Exec_Swap() uses the "SET TEMP=" from your DOS environment (if
 found), if it points to a subdirectory that doesn't have sufficient free
 space, then swap-out will fail.  The amount of space to swap out XRSDoor is
 128K.  If you have less than that amount of space on the "TEMP" drive and
 enable "Swap", you must use a batch file and set the point "SET TEMP=" to
 another drive when XRSDoor is running, then switch it back to the original
 subdirectory when it is through.  (also, note that if you have 128K of EMS
 or XMS memory free for swapping, this does *not* apply to you!)

13) To enable alias support, the user must go to the "<O>ption Toggle" switch
 configuration sub-menu and turn on the "Using XRS 4.52 or later?" option.  I
 had to do this, or it would cause any older XRS versions to quit with a "Bad
 User" exit 91 error (file tampering).  XRSDoor now assumes all users have XRS
 3.21 or later (therefore always produces "named mailbags").  XRSDoor puts a
 special "tag" into the user file to enable user aliases.  Without the special
 signature, aliases are disabled.  Aliases are not supported by any versions
 of XRS prior to 4.52!  Unless the user enables alias support for himself, an
 old-style 43-byte "USERx.XRS" file is written regardless of whether or not he
 has a "registered" alias, if he enables this feature, and new 68-byte file is
 written which includes his alias and the file "signature" is updated.  The
 same switch which formerly was used to indicate "Using XRS 3.21" or later was
 reused for this option - therefore anyone using XRS 3.20 or prior versions
 will no longer receive "unnamed mailbags" and *must* upgrade at this point!

14) If you use "SysOpOut xxxx" and want to enable 4D-packing, just copy the
 '4D-PACK.XRS' file over to your SysOpOut subdirectory (or create one there).

15) An ugly bug in my code caused the program to go nuts on the fifth call to
 XRSDOOR in one execution of PackBags (go figure!).  I wasn't closing the user
 file "USERS.BBS" every time, and reopened it (in share mode if applies) each
 time.  This should have eventually exhauseted your available file handles and
 died, but I'm at a loss as to why this error would cause the computer to go
 nuts reading a file and start streaming output endlessly to the datafiles!
 PackBags.Exe version is now 0.50 - I think it's about ready for "prime time".

16) The "MSGTXT.BBS" file is closed as soon as extraction is completed and
 not held open even during compression and download.

17) XRSDoor uses PKPAK and PKUNPAK instead of PKARC and PKXARC.

18) New XRUserEd.Exe program (which does *NOT* require the old XRS$CORE.RTL or
 XRS$ALL.DTA files to run!) that runs under DOS 5.0 without "LoadFix.Exe".
 (But it *does* need the new XRS 4.52 standard "XRSLANG.DLL" file for English
 language support or any other foreign language XRS 4.52/5.0-compatible native
 language support binary overlay plus the XRSCORE.DLL library for Borland C++
 and C_Worthy run-time library - after all - what did you expect from a < 9.5K
 program?  (does an awful lot, eh?)





      XRS "eXpress Response System" (R) Door version 2.03 changes:

Went back to the original release BC++ 2.0 to eliminate the bug in the newer
compiler which caused wierd "local" displays (although the user side was OK)





      XRS "eXpress Response System" (R) Door version 2.02 changes:
            (since version 2.01)

1) PackBags.Exe is an automatic (pre-packing) mailbagger for XRSDoor.  It
scans through your QMX_CONF.SYS file looking for your "Priveleged" users
which you have marked with the "Prepack" bit-flag, and automatically creates
the files required and calls "XRSDoor!.Exe" (if it is not found "XRSDoor.Exe")
to do the actual extraction and compression.  Each person's pre-bagged mail
will be saved under a unique 8-hexidecimal digit name, with the user-selected
extent depending on which compaction he has chosen (i.e. "2fa839d1.ZXR" up to
*.ZX9, assuming the user selected PKZip packing - at most 10 files saved for
any one user.  PLEASE BE CERTAIN YOU HAVE XRSDOOR SETUP AND OPERATING PROPERLY
BEFORE YOU EVEN THINK ABOUT IMPLEMENTING THIS PROGRAM!  You must chose which
users are allowed to have prepacked mail by using the "XRUserEd.Exe" program
that comes with XRSDoor (set the 'P' bit - "Prepack" under the "Toggle switch"
submenu).  I would suggest that you only run PackBags once a day, in which
case it will store up to 10 mailbags for a user while they are on vacation,
etc.  (once it has 10 mailbags on "hold" it will not pack any more for that
user)  PackBags stores its log in a separate "PackBags.LOG" file which you
may wish to delete occasionally, after assuring it is working correctly.
          * * * * * *  W A R N I N G  * * * * * *
Please be careful here - you can easily get into the habit of saving 100's of
kilobytes of mail for people, which XRSDoor is designed to avoid (i.e. prepack
problems associated with supporting a large number of "real" points).  This
feature should be reserved for your best users depending upon your disk drive
capacity, etc.  Using this feature wisely to give your best XRS users mail on
demand (and prepacking during the "midnight" or one event early each day) can
save users still more time online (and give you an opportunity to have more
users online per day, too!).

2) Several minor changes were made to accommodate "PackBags.Exe" - the
automatic mailbagger.  XRSDoor was also modified to look for the special
saved files, and offer to download them as soon as the user comes into the
door the next time (or he may chose to defer or store them until later, or
delete them).  PackBags creates a mailbag with a unique name by performing a
32-bit CRC on the username, and renames the normal output file.  XRSDoor now
knows the 'named mailbag' name for saved mailbags for each user.  For the time
being, batch protocols only (True Y-Modem, Z-Modem or G-ymodem) must be used.

3) The FOSSIL input routine immediate "timeout" if the user started XRSDoor
within three minutes before midnight is fixed.

4) New QMXSETUP.CFG parameter "Minimum xxx" allows you to set a minimum count
of new messages in the mail databases before XRSDoor.Exe will prepack mail -
range is from 50 to 1000 messages.  It only affects XRSDoor when it is called
by PackBags.  I would suggest that you set it to at least 250 messages - note
that the maximum number of messages packed (which has nothing to do with how
many new messages total are on file) is going to always be the number you set
using "Limit" parameter, which will avoid creating bundles too large for your
your users.  The default is 250.  Setting this to a reasonable number, say
500 or 1000 (depending on the average daily volume of mail coming into your
system) gives you the ability to prepack mail more often, but only when a
certain minimum number of new messages have been received.

5) New QMXSETUP.CFG parameter "PackbagPath xxxxx" allows you store prebagged
mail in another subdirectory insteaed of the current directory.  Parameter is
*REQUIRED* for multi-node systems to work properly, and in this case must give
a complete PATH.  THE SUBDIRECTORY *MUST* BE ON THE SAME DRIVE!  For single
line systems, using "PackbagPath C:\SaveBags" would store prebagged mail under
a subdirectory named "SAVEBAGS" off the root of the C drive for example, and
"PackbagPath C:\QMX\SAVEBAGS" would save all packed mail in that subdirectory
for a multi-line system.  Be sure to include the complete path - be certain
that it already exists! (and that it is on the same drive)

6) New QMXSETUP.CFG parameter "GMODEM" enables G-Modem for selection.  Prior
versions always showed it, even though it may have been inappropriate.  If you
have an error-correcting modem, you should turn this on, otherwise it will no
longer be offered.  Note that if you don't have a registered copy of DSZ.COM
or GSZ.COM, this parameter will not function, anyway!

7) Normally, "PackBags.Exe" searches QMX_CONF.SYS for users the SysOp has
marked for PrePack, creating the EXITINFO.BBS and DORINFO1.DEF files for each
user and calling XRSDoor.  If you type a name on the command-line, PackBags
only looks for a matching username in the file, and if found creates the two
required files, packs mail for that one person (without regard to "Minimum")
and exits.  This allows "On Demand" packing (for someone not necessarilly
marked for prepacking) - this might be used for a "Mailer Request" function.

8) PackBags knows nothing about which type of Hudson-style BBS it is running
on, and needs to know if the USERS.BBS and/or QMX_CONF.SYS files are hiding
in another subdirectory.  If one (or both) are, use a new "MessagePath xxxxx"
QMXSETUP.CFG parameter, where 'xxxxx' is the path to the file(s).

9) The error which allowed users to send "Crash" netmail if they had the
"Prompt for maximum number of messages" bit set is fixed.  Note that XRSDoor
determines whether or not a user has "Crash" priveleges solely by the flag in
QMX_CONF.SYS (which you set with XRUserEd.Exe) - it pays no attention at all
to any other settings.






      XRS "eXpress Response System" (R) Door version 2.01 changes:
            (since version 2.00)


1) Fixes problem with RA 1.10 versions, which provide the true carrier rate
for new connect speeds when used with the new CCITT V.32bis modems.  XRSDoor
now recognizes 14400, 12000 and 7200 BPS rates as legitimate.

2) You can select "AR<J>" from the compression type selection sub-menu in the
configuration section.  The menu which was previously here has been replaced
with a simpler one-line prompt.  XRSDoor defaults to "PKZip" for packing.
ARJ is only recognized by XRS 4.50 versions dated June 15th, 1991 or later!

3) "InDir" can be on another drive, allowing you to use a RAM-disk, etc.

4) XRSDoor recognizes and includes "4D_PACK.XRS" in every mailbag if you
place that file in your subdirectory (content unimportant - can by 0 length).
This forces XRS 4.50 versions dated June 15th, 1991 or later to return you a
true 4D packet with zone:net/node.point all filled out in the *.PKT header.
IMPORTANT NOTE:  DO *NOT* USE "POINT 0" IN COMBINATION WITH 4D_PACKing! (the
result will be that both the 4D "from" and "to" addresses are idential...)

5) A new "XRUserEd.Exe" is included that will show/set "ARJ" for compression.
XRUserEd requires both the file "XRS$ALL.DTA" and "XRS$CORE.RTL" found in the
XRS release archives.  Also, note that you must be in the same directory as
the "QMX_CONF.SYS" file when you run it (and if "AREAS.BBS" is in a different
subdirectory, that subdirectory must be used as a command-line parameter).

6) "Alien" uploaded files are moved to a subdirectory named "XRS_DOOR.BAD"
and deleted from the "InDir" (anything that cannot be unpacked/interpreted).
If the subdirectory doesn't exist, XRS creates it.

7) "MSGTOIDX.BBS" is no longer left open during message pack and download.

8) The "Clean_Up()" routine is executed as soon as files are successfully
compressed instead of after the download is completed.  This eliminates all
of the *.XRS files packed into a mailbag before the transfer, optimizing use
of disk space (especially important on multi-line systems / large mailbags).

9) XRS can use the new "GSZ.EXE" (full-screen version of DSZ).  Put "Use GSZ"
into your QMXSETUP.CFG file, it is used instead of DSZ.COM for transfers.

10) If "MkXrs" is called to import mail after an upload, the "HighMsgRead"
pointer is updated properly, so users with the "Include" (from me) toggle on
do not see their own messages twice - when they are uploaded and next time.

11) If the file "QUICKCFG.DAT" is found, QuickBBS 2.75 or later format files
are used and RA and SuperBBS support checks are bypassed.  XRSDoor uses that
file and "MSGCFG.DAT" instead of CONFIG.BBS (or CONFIG.RA and MESSAGES.RA).
(note - this includes full multi-line support with file-sharing)  XRSDoor
also recognizes AKA addresses for QuickBBS 2.75 and later.   XRSDoor pulls
the node number for Quick275+ from the QUICKCFG.DAT file and ignores the "SET
TCNODE=x" in the environment (if any).  If multi-line QuickBBS 2.75 or later
is being used, the "QMX_CONF.SYS" (user default selections file) is kept in
the message subdirectory - if you now have it somewhere else (in the current
directory) you *MUST* move it!  The "SET QUICK=xxxx" environment string is
used to find files (i.e. "xxxCFG.DAT") if they are not in the current dir.

12) The availability of "Crash" netmail works for any version of QuickBBS.

13) XRSDoor puts the alias supported by RA 1.0 and later or QuickBBS 2.75 and
later into the USERx.XRS file for use by future XRS versions.

14) The status bar no longer scrolls up (and off) the screen if you have lots
of new files displayed.

15) XRSDoor sets the "Alias" flag in ACCESSx.XRS if the SysOp allows it, the
 "Local" flag in ACCESSx.XRS for local areas, and the "Netmail" bit is set
 for all netmail areas, not just the first one encountered.  WARNING!!!  If
 your echomail mangler insists it can't handle origin-less message, you can
 *NOT* use the "Local" bit, since XRS will put a local tagline rather than a
 complete Fido-spec tear and origin line into "Local" messages (4.52!)  If
 this is the case - you have two choices - get a better mail mangler or set
 the parameter for the local areas to make them look like echomail again...